Nowadays, mobile devices (e.g., smartphones, tablets) are increasingly being used to perform sensitive electronic transactions, and also to store a considerable amount of private and confidential information.
While the systems and services offered over transaction mobile devices became more valuable, sophisticated and in widespread use, the incidence of malicious software (malwares) and fraudulent transactions have also increased. There are many security threats associated to mobile devices, which have been successfully hacked, making it possible to a third party (attacker) to fraudulently obtain the user's password and/or any other sensitive information (e.g., credit card numbers, bank account information, private photos/videos, etc.).
Most of current smartphones uses Android Operating System (OS). Therefore, it is understandable why most of malware attacks are driven to Android OS. And it is also well-known that Android Security Model has vulnerabilities. Badly written/coded applications (i.e., a programming fault) may permit a possible attack vector in the inter-application communication, and consequently a malware may achieve unauthorized access to Android application data, but this is not the only reason for Android security vulnerabilities. Besides badly written/coded applications, there are other ways to attack applications and exploit these vulnerabilities if an attacker (cracker) has a “ring0” control or enough access/privileges (“process trace” or “ptrace” is a simple example, where one process can control and manipulate the internal state of another process).
In fact, the increasing number of malware and cyber attacks in the last few years illustrates those Internet and security vulnerabilities on Android operating system: recently, Interpol (International Criminal Police Organization) and Kaspersky Lab (an Internet security software company) conducted the “Mobile Cyber Threats Survey” (published on October 2014), which revealed that more than 588.000 Android users worldwide were attacked by financial malware between August 2013 and July 2014, which is six time greater (600% rise) than the number from the equivalent period 12 months earlier (i.e., August 2012 to July 2013). Additionally, the survey estimates that 98.05% of all existing mobile malware targets the users of Android devices; and only in the first half of year 2014, 175.422 new unique Android malwares were detected. More details can be found on the mentioned “Mobile Cyber Threats Survey”, available online at: http://media.kaspersky.com/pdf/Kaspersky-Lab-KSN-Report-mobile-cyberthreats-web.pdf?_ga=1.54425199.671458092.1427292679).
For these and other reasons, one can clearly notice that the vast majority of mobile cyber-threats is driven to Android OS and, unfortunately, attackers still have (undesirable) success rates. Internet vulnerabilities remain a problem in Android devices.
Therefore, there is a need to provide a way to prevent the operation of malwares while critical applications are running, consequently avoiding the fraud/compromising of the transaction, minimizing cyber-threats and the theft of private/confidential information being used by the application during its execution.
Patent document U.S. Pat. No. 7,849,311 B2, titled “Computer System with Dual Operating Modes”, published on Dec. 7, 2010, discloses the method and system to create a computer Secure Mode. The described system implements a secure and non-secure file system, then one or another file system is mounted, in order to determine the operation mode. Once the file system is mounted, only the applications present therein will be allowed to execute. In summary, it implements a kind of container that contains applications that will be allowed to run in a specific mode. The drawback of this solution is that the method cannot protect against simple attack of privileged user, since the secure file system can be mounted any time and a malicious application can be embedded/inserted. Additionally, this is not a good solution for non-corporate users, since there is a good chance to have malicious code/software of vulnerable application installed inside the secure mode, making it vulnerable as non-secure mode.
Patent document U.S. Pat. No. 8,499,171 B2, titled “Mobile Security System and Method”, published on Jul. 30, 2013, discloses a system and method for providing a secure environment for mobile telephones and other devices. The system and method may use trusting zones, in layered memory, and a secure matrix model having, for example, a memory protection module for protecting memory; a secure debug module for ensuring security of the debug module; a secure file system module for protecting the secure file system; and a trusted time source module for protecting components. This concept is already present in the market as Samsung KNOX solution uses it. The solution disclosed in U.S. Pat. No. 8,499,171 B2 patent is robust, but a special hardware is required, increasing the cost of the product. Additionally, applications in the market must be rewritten to use a special API to be allowed to run in the secure environment, it makes the adoption of such technology very difficult by non-corporate users.
In the current state of art, we have found solutions and technologies that use the concept of containers to create different environments in the same device, isolating groups/clusters of applications. However, existing solutions would not protect the applications inside the container if it is infected by a malware. In fact, if the container is already infected by a malware with high privilege, data interception is possible: for instance, the malware could perform a “memory dump” on the application which is running and manipulating the data (by “ptrace”, or in “ring0 control”). In this case, even if the data and/or applications are stored in a container, it is not possible to ensure that it is completely “safe”. In other words, as long as the malware can execute/run/operate in the operating system environment, there is a possible risk of attacking other running applications (whether on a container or not).
Furthermore, existing technologies and solutions fail to improve the security of devices without TrustZone technology. TrustZone technology is tightly integrated into Cortex®-A processors, and is a system-wide approach to security for an array of client and server computing platforms, including handsets, tablets, wearable devices and enterprise systems. The applications provided by the current technology are extremely varied but include payment protection technology, digital rights management, “Bring Your Own Device” (BYOD) and a host of secured enterprise solutions. Non-corporate users do not adopt most of container-based solutions using TrustZone/TEE, such as Samsung MyKnox since most of devices in the market do not support MyKnox. TrustZone/TEE demands higher hardware specifications/requirements (processor, memory, etc.), which restricts the use of this technology only to current flagship/high-end smartphone models. Therefore, there is a need to provide a “lightweight” solution, which is able to improve the security and also can be supported by most of devices.
Another important observation about the use of container-based solutions: sometimes the applications to be used inside the container must be rewritten to use the TrustZone API. It means that even using TrustZone/TEE technology, it is not a guarantee that all important user applications (such as messengers, bank applications, etc.) are protected (unless they are using said API, TrustZone/TEE based solutions fail on really protecting these applications).
It is also important to differentiate the proposed solution from the well-known “application whitelisting” concept. Traditional “application whitelisting” techniques just specify applications to run. That said, these applications can still attack each other (since there is no other security restriction applied to the “application whitelisting”).
Differently, the proposed solution of the present invention requires that applications should be pre-approved to execute on “secure mode” and, to produce the desired effect, these applications should also be executed on “Secure Mode” enabled, wherein many security restrictions are applied (it will be further detailed below). That said, even with a group of applications running together on “secure mode”, they are protected against each other by security restrictions (it is not true to “application whitelisting” concept).
Therefore, one person skilled in the art can notice that the proposed solution goes beyond the well-known “application whitelisting” concept, by offering not only a way to configure a “pre-approved list of applications to be executed” (in a similar manner of the “whitelist” concept), but additionally providing means to apply security restrictions to these applications.
In this scenario, it is necessary a solution that can be easily used by users in order to avoid cyber-attacks that exploits the existing Android OS security vulnerabilities, aiming to add more resilience into the current operating system, even if it is infected and regardless of whether or not the user is using a container solution.
Our proposed solution will not require hardware modification, application or modification of a new secure file system. The user will use the device as it was originally designed. The application can be installed in the same environment. The new secure mode proposed for mobile will allow users to run only selected critical applications when the mode is enabled and will enforce access permissions when it is disabled. That said, even if the environment is infected, the malware will not be allowed to run and will not be allowed to modify benign files from critical applications, even if secure mode is disabled.